Day9鐵人賽文章 有提到可以使用 Suspense
來切分 server component 的 chunk,達到流式渲染(streaming)的效果,讓使用者體驗 upup。
但只用感覺不好量化使用者體驗究竟好了多少,Google 提出了網站指標(web vitals)來檢測網頁的使用者體驗好不好。
接下來會以 web vitals 的角度來看 streaming 對於使用者體驗具體有哪些方面的提升。
web vitals 是由 Google 提出的,用於量化網頁上使用者體驗的指標。開發者可以藉由這些指標有一個明確的改善方向,比較常見的方式可以用 lighthouse 查看,按下 F12
也可以看到一個 lighthouse 的頁籤,這裡可以讓我們查看網頁的 web vitals,獲得一些網頁的改善建議。
其他的 web vitals 通常也可以當成主要 web vitals 的代理指標,這些其他的指標當中,也可以看出特定的問題。
web vitals 的區間為:好、普通、差。
如果以下的 web vitals 指標不影響到主要的 web vitals,那也不一定要將這些 web vitals 調整到「好」這個區間。
講完了 web vitals,接下來聊聊過去的 SSR 與 web vitals 有什麼關係。
過去的 SSR 會在 server fetch 完所有的資料,才會把內容回傳到 client 端,對應的 web vitals 如下圖所示。
A:在 server fetch data 的時間
B:接收到資料後,在 server 把 html build 好
(B 的結果傳送到 client 才算 TTFB)
C:傳送 html 與 react component 到 client
(C 將整塊 html 渲染出來時算 FCP)
D:執行 react component,並且與 html 進行 hydration 的期間
(hydration 完成後才能開始互動 TTI)
我們必須要在 server fetch 完所有資料才能進行渲染,這導致所有流程非常的 waterfall,A 全部執行完成才到 B,然後接著下去。
畫面也會從空白直接跳到顯示所有內容,最後再一起 hytrating。瀏覽器在等待的時間完全沒事做,直到 TTFB 才一次執行完整個頁面所需的 code,屬實有點浪費瀏覽器的這段空窗期。
使用 streaming 的方式渲染頁面就可以大大的改善上面的問題,因為渲染的區塊被我們切割,分段式的傳給瀏覽器執行上面講到的 ABCD 這四個動作。
這可以大大改善 TTFB, FCP, TTI 這三個指標。
上面這三段就相當於切分了三個 chunk(還不知道 chunk 的可以看 Day9鐵人賽的內容),這三個 chunk 分別執行了 ABCD 這四個動作,而 web vitals 這三個輔助指標主要是看第一個渲染的 chunk,所以這大大的提高了 web vitals 的分數。
當然實際的 LCP 指標還是要看渲染最大區塊的 chunk 何時完成,在優化時也可以減少 LCP chunck 的渲染時間,這就看自己想怎麼優化了~